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Chapter  1 

Introduction 


This  report  presents  procedures  that  identify  how  Defense  transportation  elec¬ 
tronic  data  interchange  (DTEDI)  trading  partners  implement  a  new  version  of  the 
Accredited  Standards  Committee  (ASC)  XI 2  electronic  data  interchange  (EDI) 
standard.  To  successfully  prepare  and  implement  an  EDI  migration,  trading  part¬ 
ners  need  to  justify  migration,  assess  and  approve  the  migration,  prepare  for  mi¬ 
gration,  and  implement  the  migration  version  in  a  production  environment.  By 
following  this  procedure,  trading  partners  can  ensure  a  smooth  implementation. 

What  Is  Version  Migration? 

Upgrading  EDI-capable  computer  systems  to  a  new  version  of  an  XI 2  EDI  stan¬ 
dard  is  commonly  called  “migration.”  It  calls  on  trading  partners  to  update  EDI 
translation  software,  user-defined  file  formats,  and  application  database  systems. 
However,  migration  is  not  only  a  technical  accomplishment.  In  addition  to  up¬ 
grading  systems,  migration  calls  on  trading  partners  to  implement  new  business 
requirements.  For  example,  in  the  near  future,  the  DTEDI  community  will  imple¬ 
ment  a  new  business  practice  for  managing  and  exchanging  line  of  accounting  in¬ 
formation.  As  the  community  migrates  to  a  new  version  of  the  XI 2  standard,  it 
will  need  to  migrate  to  a  new  business  practice. 

Why  Develop  Migration  Procedures? 

EDI  translation  software  allows  a  nearly  transparent  migration  between  versions 
of  the  X12  standards.  However,  the  Defense  experience  with  a  3050  migration  has 
been  arduous  and  has  taken  over  a  year  to  implement.  Consequently,  this  proce¬ 
dure  was  developed  to  enable  a  structured  migration. 

How  Is  This  Report  Organized? 

This  report  establishes  a  procedure  for  future  migrations  and  addresses  key  topics 
in  the  following  four  chapters: 

♦  Chapter  2  describes  business  and  technical  conditions  that  dictate  a  re¬ 
quirement  to  migrate. 

♦  Chapter  3  explains  how  the  data  maintenance  (DM)  task  group  evaluates  a 
potential  migration,  recommends  the  migration,  and  gains  DTEDI  Com¬ 
mittee  approval. 
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♦  Chapter  4  describes  the  key  steps  DTEDI  trading  partners  take  to  prepare 
for  migration. 

♦  Chapter  5  outlines  the  final  implementation  process. 

In  addition,  Appendix  A  identifies  the  procedures  for  implementation  convention 
(IC)  publication  and  DM  during  migration.  Appendix  B  describes  the  system  inte¬ 
gration  test  (SIT)  for  certifying  trading  partners’  readiness  for  implementation. 
Appendix  C  lists  abbreviations  used  in  this  report. 
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Chapter  2 

Justify  Migration 


The  publication  of  a  new  version  of  an  ASC  X12  standard  version  presents  an 
opportunity,  but  not  the  requirement,  for  a  business  community  to  migrate.  Two 
conditions  require  a  migration:  old  standards  cannot  support  current  data 
requirements  and  a  policy  external  to  the  DTEDI  community  requires  its 
compliance. 

Old  Standards  Cannot  Support  Data 
Requirement 

The  X12  Committee  revises  its  standards  in  response  to  the  business  demands  of  a 
very  large  EDI  community.  The  revisions  include  adding  code  values,  increasing 
field  sizes  to  accommodate  data  requirements,  or  restructuring  transactions  to 
handle  more  complex  data  groupings.  Two  or  more  trading  partners  clearly  need 
to  migrate  to  an  accommodating  version  of  XI 2  if  their  business  processes  require 
the  implementation  of  those  revisions. 

New  Policy  Requires  Migration 

Migration  may  also  be  required  if  the  government  establishes  a  new  or  has  an  ex¬ 
isting  policy  that  requires  the  DTEDI  community’s  compliance.  The  following 
examples  illustrate  the  two  types  of  new  policies: 

♦  Defense  policy.  After  becoming  the  lead  agent  to  manage  the  electronic 
commerce  telecommunications  infrastructure  for  the  Department  of  De¬ 
fense,  the  Defense  Information  Systems  Agency  (DIS A)  mandated  that  the 
Defense  transportation  community  migrate  its  implementation  conventions 
to  ASC  X12  Version  003050.  This  action  was  required  because  DISA  had 
established  the  003050  version  as  its  baseline  for  X12  standards  compli¬ 
ance  edits. 

♦  Federal  policy.  If  the  federal  government  mandates  that  all  EDI  trading 
partners  become  year  2000  compliant,  Defense  transportation  trading  part¬ 
ners  need  to  migrate  to  ASC  X12  Version  004010. 
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Chapter  3 

Assess  and  Approve  Migration 


The  DTEDI  community  assesses  and  approves  a  migration  in  three  steps.  First, 
when  the  annual  revision  to  the  XI 2  standards  has  been  released,  the  DTEDI  DM 
task  group  assesses  the  new  XI 2  standards  by  comparing  all  existing  DTEDI 
transactions  to  the  annual  revision.  Next,  the  DM  task  group  identifies  the  size  of 
the  migration.  The  task  group  then  recommends  to  migrate  a  transaction  or 
bypass  migration.  Finally,  the  DTEDI  Committee  approves  the  migration. 

Assess  New  X12  Standards 

The  ASC  X12  releases  a  new  version  of  the  EDI  X12  standards  annually.  Each 
new  version  presents  DTEDI  trading  partners  an  opportunity  for  upgrading  then- 
supported  EDI  transactions.  The  DTEDI  community  does  not  upgrade  its 
transactions  with  every  new  version.  Nevertheless,  the  DM  task  group  should 
evaluate  each  release  to  determine  the  benefits  obtained  by  a  migration.  If  the 
DM  task  group  determines  that  a  new  release  provides  insufficient  benefits,  the 
DTEDI  community  need  not  support  it.  However,  the  DM  task  group  assesses  the 
X12  standard  when  it  perceives  that  an  upgrade  is  advantageous.  The  assessment 
identifies  all  differences  between  the  most  recently  supported  version  and  the  new 
X12  version.  During  the  assessment,  the  DTEDI  Committee  identifies  new  code 
values  and  lists  mapping  and  structural  changes  that  affect  any  DTEDI  IC. 

Identify  New  Code  Values 

The  DM  task  group  may  recommend  a  migration  if  an  X12  release  introduces  a 
significant  number  of  new  codes  that  support  DTEDI  business  processes.  Migrat¬ 
ing  enables  trading  partners  to  rely  on  EDI  translation  software  to  monitor  data 
quality.  Further,  the  community  may  use  borrowed  codes  until  valid  codes  are 
available.1  Migration  makes  the  borrowed  codes  available  for  future  use. 


1  A  borrowed  code  is  a  valid  unused  X12  code  intended  for  another  context. 
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List  Mapping  and  Structural  Changes 

The  assignment  of  data  to  data  elements  is  called  “mapping.”  A  new  version  can 
discontinue  support  of  data  elements  or  segments.  Accordingly,  the  DM  task 
group  identifies  new  data  elements  for  any  information  formerly  carried  in  the 
discontinued  data  elements.  The  DM  task  group  lists  all  mapping  changes. 

The  DM  task  group  identifies  structural  differences  between  the  new  and  currently 
supported  versions.  The  task  group  examines  field  sizes;  elimination  or  addition 
of  elements  within  segments;  elimination,  addition,  or  change  in  usage  of  seg¬ 
ments;  and  changes  in  usage  or  structure  of  loops. 

Identify  Size  of  the  Migration 

As  a  result  of  the  standards  assessment,  the  DM  task  group  selects  ICs  to  migrate 
and  identifies  trading  partners  affected  by  the  migration. 

Select  ICs  to  Migrate 

The  DM  task  group  evaluates  ICs  it  needs  to  migrate.  It  assesses  all  transactions 
exchanged  through  trading  partner  interfaces.  After  determining  that  an  IC  re¬ 
quires  significant  changes  as  a  result  of  the  standards  assessment,  the  task  group 
selects  the  IC  as  a  candidate  for  migration. 

Identify  Trading  Partners 

After  selecting  the  migration  ICs,  the  DTEDI  community  identifies  the  informa¬ 
tion  exchanges  affected  by  the  migration.  As  a  result,  the  task  group  can  identify 
the  trading  partners  who  use  the  IC.  The  trading  partners  should  be  included  in  all 
migration  activities. 

Migration  Recommendation 

Based  on  the  results  of  its  evaluation,  the  DM  task  group  develops  a  recommen¬ 
dation  for  each  DTEDI  transaction.  The  recommendation  can  be  to  migrate  the 
transaction  or  bypass  migration.  The  DM  task  group  sends  its  recommendation  to 
the  DTEDI  Committee. 

Migrate  Transaction 

When  the  DM  task  group  recommends  to  migrate  a  transaction,  it  prepares  a  list 
of  new  code  values  and  mapping  changes  imposed  by  the  new  X12  version. 
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Assess  and  Approve  Migration 


Bypass  Migration 

The  DM  task  group  recommends  to  bypass  migration  if  it  determines  the  migra¬ 
tion  does  not  benefit  the  DTEDI  community.  A  bypass  recommendation  retires  the 
inquiry  until  the  next  XI 2  version  or  a  significant  change  occurs  in  the  DTEDI 
community’s  business  needs. 

Gain  DTEDI  Approval  of  Migration 

A  decision  to  migrate  requires  the  concurrence  and  cooperation  of  all  participants 
on  the  DTEDI  Committee.  Following  its  standard  voting  procedures,  the  commit¬ 
tee  votes  on  the  DM  task  group’s  recommendation.  After  deciding  to  migrate  a 
transaction,  the  community  begins  to  prepare  for  migration. 
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Chapter  4 

Prepare  for  Migration 


To  prepare  for  migration,  the  DTEDI  Committee  completes  the  following  tasks: 

♦  Perform  preliminary  impact  analyses.  Each  trading  partner  compares  its 
current  IC  data  requirements  with  the  XI 2  standards  assessment  com¬ 
pleted  by  the  DM  task  group.  Trading  partners  develop  appropriate  system 
change  requests  and  estimate  the  time  required  to  complete  programming 
work  orders. 

♦  Create  a  new  IC.  Using  the  X12  standards  assessment,  the  DM  task  group 
develops  draft  ICs  for  all  transactions  scheduled  for  migration.  The  draft 
ICs  reflect  current  DTEDI  business  requirements.  The  DM  task  group 
follows  established  procedures  for  managing  IC  publication  and  DM  dur¬ 
ing  a  migration.  Appendix  A  describes  the  IC  publication  and  DM  proce¬ 
dures. 

♦  Align  trading  partners’  application  system  requirements.  Participating 
trading  partners  cooperate  in  a  step-by-step  check  of  each  new  IC  and, 
where  necessary,  adjust  their  EDI  techniques  to  accommodate  new  busi¬ 
ness  practices.  As  a  result  of  this  cooperative  activity,  trading  partners  de¬ 
velop  final  programming  schedules  for  system  change  requests. 

♦  Publish  an  approved  IC.  When  trading  partners  have  completed  then- 
alignment  actions,  the  DTEDI  Committee  approves  and  publishes  all  mi¬ 
gration  ICs. 

♦  Prepare  a  draft  migration  plan.  The  DM  task  group  prepares  a  draft  mi¬ 
gration  plan  that  includes  a  schedule  and  milestones  for  testing  and  im¬ 
plementing  the  migration.  This  plan  is  based  on  all  system  development 
schedules.  Chapter  5  outlines  implementation  actions. 
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Chapter  5 

Implement  Migration  Version 


When  preparations  for  migration  are  completed,  the  DTEDI  community  completes 
and  implements  the  migration  through  the  following  actions:  trading  partners  up¬ 
grade  systems,  perform  required  internal  system  tests,  and  perform  an  SIT;  and  the 
DTEDI  Committee  declares  a  production  date. 

Upgrade  Trading  Partner  Systems 

To  prepare  for  migration  testing,  trading  partners  may  need  to  enhance  their 
translation  software  and  application  programs  to  meet  any  migration-related 
requirements. 

♦  Translation  software.  To  enable  their  translation  software  to  process  the 
latest  version  of  the  standards,  trading  partners  need  to  upgrade  their 
translation  tables  to  the  latest  version  of  the  XI 2  standards.  In  addition, 
changes  in  business  requirements  may  require  an  upgrade  to  the  user- 
defined  file  (UDF)  sent  between  the  translator  and  the  application  pro¬ 
grams.  To  achieve  the  upgrade,  trading  partners  need  to  change  the  map¬ 
ping  tables  used  by  the  translator  to  produce  the  UDF. 

♦  Application  programs.  Migration  provides  trading  partners  the  opportunity 
to  upgrade  application  programs  to  meet  the  latest  business  requirements. 
This  upgrade  may  require  changes  to  input,  output,  and  processing  com¬ 
puter  programs.  Further,  it  may  require  changes  to  the  application  database 
structure. 

Perform  Internal  System  Tests 

Because  trading  partners  use  different  systems,  quality  and  acceptance  testing  may 
be  needed  for  new  system  requirements.  Trading  partners  need  to  finish  internal 
tests  in  the  assigned  time  before  participating  in  the  SIT. 

Perform  System  Integration  Test 

Trading  partners  execute  the  SIT  plan  in  Appendix  B.  Based  on  the  results  of  the 
SIT,  the  test  director  (an  organization  identified  in  the  plan)  prepares  a  final  test 
report  for  the  DTEDI  Committee. 
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Declare  Production  Date 


When  the  DTEDI  Committee  declares  that  the  SIT  is  successful,  it  establishes  a 
date  that  all  trading  partners  can  process  the  new  migration  version. 
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Appendix  A 

Implementation  Convention  Publication  and  Data 
Maintenance 


This  appendix  presents  the  seven  steps  the  DTEDI  community  follows  when  it 
migrates  ICs  to  new  versions  of  the  XI 2  standards.  Implementing  a  new  EDI 
standard  version  requires  that  trading  partners  develop  new  ICs  to  replace  existing 
versions.  At  its  January  1997  meeting,  the  DTEDI  DM  task  group  identified  the 
following  steps  for  managing  IC  publication  and  DM  during  a  migration: 

♦  Suspend  current  IC  maintenance 

♦  Publish  an  initial  draft  IC 

♦  Review  the  initial  draft  IC 

♦  Host  a  review  group 

♦  Publish  and  proofread  the  revised  draft  IC 

♦  Publish  and  distribute  the  final  draft  IC 

♦  Resume  IC  maintenance. 

The  DTEDI  technical  secretariat  takes  these  seven  steps  after  the  trading  partners 
complete  their  preliminary  impact  analysis. 

Suspend  Current  IC  Maintenance 

During  the  life  of  a  supported  XI 2  version,  the  DTEDI  DM  task  group  may 
modify  its  ICs  because  of  changing  business  requirements.  DM  actions,  voted  by 
the  DM  task  group,  accommodate  the  changes.  The  modifications  pertain  to  only 
the  most  recent  IC  version  supported  and  are  not  related  to  any  additional  previous 
version  being  maintained. 

When  a  decision  is  made  to  migrate  to  a  new  version,  the  DM  task  group  suspends 
all  DM  activities  until  a  new  version  is  implemented.  The  DM  task  group  selects  a 
DM  item  to  mark  the  DM  suspension  point.  That  DM  work  request  is  the  last 
piece  of  maintenance  included  in  the  new  IC.  (The  community  may  continue  to 
file  maintenance  requests  after  the  suspension  point,  but  they  remain  deferred 
until  a  new  IC  has  been  certified  for  implementation.)  After  DM  is  resumed,  all 
deferred  DM  actions  apply  only  to  the  new  IC  version. 
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Publish  Initial  Draft  IC 


The  DM  task  group  designates  a  trading  partner  who  develops  and  publishes  an 
initial  draft  for  a  new  IC.  The  draft  contains  all  information  relevant  to  a  final  IC, 
including  an  application  matrix,  examples,  and  code  lists.  The  developer  provides 
a  copy  of  the  initial  draft  to  the  DM  task  group.  The  DM  task  group  designates  the 
Logistics  Management  Institute  (LMI)  or  the  Defense  Logistics  Management 
Standards  Office  (DLMSO)  to  distribute  it  to  the  community  via  the  World  Wide 
Web. 

Review  Initial  Draft  IC 

The  community  reviews  the  initial  draft  IC  before  it  convenes  to  discuss  final 
changes.  In  preparation  for  the  review  group  meeting,  each  trading  partner  reviews 
the  IC  for  accuracy  and  completeness  and  prepares  comments. 

Host  Review  Group 

The  developer  hosts  an  IC  review  group  meeting  and  invites  all  trading  partners 
who  plan  to  implement  the  new  IC.  The  group  ensures  that  all  legacy  requirements 
and  pending  maintenance  items  (to  the  DM  suspension  point)  are  included  in  the 
initial  draft  IC.  In  addition,  the  group  ensures  that  the  IC  follows  EDI  standards 
syntax  requirements  and  semantic  guidelines. 

Publish  and  Proofread  Revised  Draft  IC 

After  revising  the  initial  draft  IC  with  review  group  comments,  the  developer 
produces  a  revised  draft  IC.  The  DM  task  group  distributes  it  via  the  Internet  to 
the  review  group.  Each  review  group  member  proofreads  the  IC  to  verify  the 
accuracy  of  the  revised  draft  and  provides  corrections  in  writing  to  the  developer. 

Publish  and  Distribute  Final  Draft  IC 

Based  on  review  group  comments  on  the  revised  draft,  the  developer  publishes  a 
final  draft  IC  for  the  DTEDI  community.  The  chair  of  the  DTEDI  Committee  pro¬ 
vides  notice  announcing  the  publication  of  a  final  draft  IC.  In  the  letter,  the  chair 
requires  that  all  trading  partners  perform  an  impact  analysis  of  their  systems. 
DLMSO  or  LMI,  as  directed  by  the  DM  task  group,  distributes  the  final  draft  to 
DTEDI  trading  partners  via  the  Internet. 
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Implementation  Convention  Publication  and  Data  Maintenance 


Resume  IC  Maintenance 

The  DM  task  group  does  not  perform  DM  until  the  new  IC  has  been  tested  suc¬ 
cessfully  and  is  exchanged  routinely  within  the  new  standards  version.  When 
those  conditions  have  been  met,  the  DM  task  group  announces  to  the  community 
it  is  beginning  DM  for  the  new  IC. 
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Appendix  B 

System  Integration  Test 


This  appendix  presents  a  summary  approach  for  conducting  an  SIT.  It  is  derived 
from  activities  performed  during  the  SIT  for  the  government  bill  of  lading  (GBL) 
migration  to  X12  Version  003050. 

The  DTEDI  community  conducts  an  SIT  to  ensure  that  any  change  necessitated  by 
X12  standards  revision  and  all  new  business  requirements  has  been  correctly 
incorporated  by  all  trading  partners.  Based  on  migration  test  results,  the  DTEDI 
Committee  decides  when  to  terminate  the  SIT  and  proceed  with  implementation. 

Test  Roles  and  Responsibilities 

The  DTEDI  community  selects  a  trading  partner  to  be  the  test  director.  The  test 
director  gathers  and  coordinates  test  data,  oversees  activities  by  the  trading 
partners  to  accomplish  the  test  objectives,  and  presents  results  to  the  DTEDI 
Committee. 

Representatives  from  each  migrating  system  constitute  the  test  team.  The  test 
director  is  provided  a  primary  point  of  contact  for  each  system  involved  in  the 
test.  The  points  of  contacts  are  the  data  gathering  coordinators  who  report  test 
results  for  their  system  to  the  test  director.  Data  gathering  coordinators  monitor 
test  transactions;  collect  test  statistics  required  by  the  test  director;  and  identify 
and  report  all  technical  problems  (these  include  communications,  data  quality, 
standard  edits,  missing  data,  transaction  formats,  error  correction,  and  translation) 
and  other  aspects  of  the  test.  Each  trading  partner  determines  if  the  objective  has 
been  successfully  accomplished  at  its  interface  for  each  testing  stage. 

Test  Plan 

The  DM  task  group  prepares  a  plan  for  testing  the  migration  to  a  new  version.  The 
plan  addresses  the  following  five  distinct  stages  of  the  test:  test  data  preparation, 
measures  of  performance  (MOPs)  development,  translation  test,  application  test, 
and  overall  evaluation.  Testing  at  each  stage  needs  to  be  satisfactorily  completed 
by  a  trading  partner  for  all  test  cases. 
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Prepare  Test  Data 


This  step  calls  for  test  participants  to  prepare  test  cases  for  translation  and  appli¬ 
cation  testing  and  assign  test  identification  data,  such  as  fictitious  GBL  numbers, 
Department  of  Defense  activity  address  codes,  and  GBL  office  codes. 

Trading  partners  are  selected  to  generate  test  data  that  they  exchange  using  the 
various  EDI  interfaces.  In  addition,  the  test  director  develops  a  test  activity  form 
template  for  recording  test  activities  and  distributes  it  to  all  test  participants. 

Develop  Measures  of  Performance 

For  trading  partners  to  gauge  their  test  results  on  an  equal  scale,  they  develop 
MOPs  for  the  test  and  identify  a  rating  scale  for  each  measure.  For  example,  a 
MOP  can  be  that  the  translation  should  result  in  only  one  syntax  error  per  10,000 
transaction  sets.  The  MOPs  ensure  that  all  trading  partners  are  satisfied  with  the 
integration  test  before  they  implement  the  migration. 

Perform  Translation  Test 

During  the  translation  test,  trading  partners  process  each  test  case  to  authenticate 
the  ability  of  translation  software  of  each  participating  system  to  accept  and 
translate  incoming  transactions  and  generate  ASC  X12  transaction  sets  997,  and 
reject  incoming  transactions  and  generate  997s.  This  action  also  verifies  that 
translators  are  checking  ASC  X12  syntax. 

To  participate  in  the  test,  all  affected  trading  partners 

♦  exchange  applicable  test  cases  and  997s  with  their  usual  trading  partners, 

♦  record  results  on  test  activity  forms,  and 

♦  resolve  problems  and  retransmit  test  cases  as  necessary. 

Translation  testing  is  complete  when  all  participating  trading  partners  have  suc¬ 
cessfully  translated  and  recorded  results  for  each  test  case. 

Perform  Application  Test 

The  application  test  evaluates  the  use  of  test  data  by  the  trading  partners’  applica¬ 
tion  systems  and  enables  trading  partners  to  modify  their  systems  as  required. 

To  test  applications,  each  trading  partner 

♦  repeats  the  exchange  of  translation  test  data  (including  all  compliance 
checking), 
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♦  records  results  on  test  activity  forms,  and 

♦  resolves  problems  and  reprocess  test  cases  as  necessary. 

Application  testing  is  complete  when  all  participating  trading  partners  have 
successfully  processed  test  case  data  and  recorded  results  for  each  test  case 
exchanged. 

Report  Final  Evaluation 

As  test  transactions  are  processed  throughout  the  entire  system,  trading  partners 
gather  data  on  any  problem  caused  by  migration  version  changes.  After 
concluding  testing,  the  test  team  holds  a  test  evaluation  meeting  to  evaluate  all 
findings.  It  prepares  a  test  analysis  report  and  presents  it  to  the  DTEDI 
Committee.  The  report  addresses  any  corrective  action  needed.  Based  on  the 
corrective  actions,  the  DTEDI  Committee  decides  to  terminate  or  extend  the 
migration  test. 

Perform  Integration  Test 

This  step  tests  the  end-to-end  EDI  process.  All  trading  partners  who  exchange 
transactions  need  to  participate  in  this  step  and  perform  the  following  activities  for 
each  IC  identified  for  migration.  For  each  test  case  that  trading  partners  exchange 
during  the  integration  test,  the  following  steps  are  used: 

♦  The  sending  partner 

►  generates  the  outbound  UDFs  from  its  application  system, 

>-  uses  translation  software  to  translate  the  UDF  into  an  outbound  EDI 
transaction,  and 

>-  sends  the  outbound  EDI  transaction  to  the  receiving  partner. 

♦  The  receiving  partner 

>-  receives  the  inbound  EDI  transaction, 

►  uses  translation  software  to  translate  the  inbound  transaction  into  a 
UDF  and  generate  a  functional  acknowledgment  for  each  transaction 
and  returns  the  functional  acknowledgement  to  the  sending  partner, 

►  processes  the  UDF  into  the  application  system,  and 

>-  performs  application  edit  checks  on  the  inbound  transaction  data  as 
required. 
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Trading  partners  may  develop  performance  reports  for  each  step  and  rate  the  re¬ 
sults  of  the  step  using  the  MOPs.  Trading  partners  declare  a  SIT  successful  when 
they  are  satisfied  that  performance  is  acceptable. 


Appendix  C 

Abbreviations 


ASC 

Accredited  Standards  Committee 

DISA 

Defense  Information  Systems  Agency 

DLMSO 

Defense  Logistics  Management  Standards  Office 

DM 

data  maintenance 

DTEDI 

Defense  Transportation  Electronic  Data  Interchange 

EDI 

electronic  data  interchange 

GBL 

government  bill  of  lading 

IC 

implementation  convention 

LMI 

Logistics  Management  Institute 

MOP 

measure  of  performance 

SIT 

system  integration  test 

UDF 

user-defined  file 
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